Cloud-based content management services and platforms have changed the way personal and corporate electronically stored information objects (e.g., files, images, videos, etc.) are stored, and has also changed the way such personal and corporate content is shared and managed. Some cloud-based systems facilitate access and/or collaboration related to such objects by storing information associated with the objects in a relational database. For example, a row in a table comprising the relational database might correspond to a file, while another row might correspond to a folder. Other attributes (e.g., columns) in the tables can describe logical relationships among the objects (e.g., file A is a child of folder B). As the usage of cloud-based systems increases, the number of objects in a given folder and/or the number of collaborators of such objects and/or folders commensurately increases. In such cases, the database transactions associated with certain folder operations (e.g., delete, move, copy, restore, etc.) over such large folders can result in increasingly longer transaction durations and, in some cases, transaction failure.
Unfortunately, legacy approaches for implementing large folder operations in the foregoing environments can be deficient at least as pertaining to transaction latency, collaborator efficiency, computer resource usage efficiency, and other factors. Specifically, such legacy approaches might run a single database transaction for each folder operation. However, handling a folder operation in a single database transaction can precipitate several problems. For example, as the size of the operation increases, the latency of the transaction also increases. In some cases, a single database transaction for a large folder operation can take many hours or days to process. Locks on the objects involved in the transaction might also be enforced while the transaction executes, resulting in many collaborators having limited or no access to the objects during the folder operation (e.g., for hours, days, etc.), which in turn decreases collaborator efficiency and satisfaction. The number and duration of concurrent locks maintained can lead to increased lock contention, which can in turn lead to decreased database performance. As more long-running transactions are introduced, an increase in computing resources (e.g., memory, disk space, etc.) may be required so as to manage the increase in the number of concurrent locks. Further, lock contention latency as well as the number and scope of concurrent locks maintained at any given moment in time can increase with such legacy approaches, resulting, for example, in an increase in the number of lock wait timeout errors experienced by other contending operation requests. In some cases, an impatient collaborator might invoke a large folder operation multiple times (e.g., thinking the first operation “didn't take”), thus further exacerbating the aforementioned deleterious effects.
Tracking non-committed changes and/or replicating the large volumes of changes in a distributed computing system (e.g., cloud-based system) for such large transactions can further result in inefficient use of storage resources and/or computing resources, respectively. In some cases, certain legacy approaches apply user limits to the number of objects in a given folder. Other legacy techniques implement other “throttling” techniques so as not to exceed certain database transaction capabilities (e.g., database server capabilities). However, such limits reduce the efficacy of the content management and/or collaboration benefits of the cloud-based platform. For example, in a large enterprise setting, the number of objects in any particular level of hierarchy (e.g., folder) can become far larger than any artificially imposed limits (e.g., “throttle limits”).
What is needed is a technique or techniques to improve over legacy and/or over other considered approaches. Some of the approaches described in this background section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.